I'd be okay with declaring that size is always bytes. But that will be a specific attribute with one purpose. There is no way of providing information on the magnitude of any data asset being described that does not lend itself to a byte count. Whether or not anyone cares or needs that descriptor is the question, but that was part of the discussion over in #101. If all you are doing in an app is notifying users with something they will read and interpret for their purposes, then it can just be a text field with whatever units or description included. If you're going to provide some feature that lets a user say something like, "Only show me datasets that are less than 10GB because that's all I can reasonably download," then that's where this interpretation of size would need to come in.

I think, if you want to have some textual descriptor, you should add new fields for those purposes. dcterms:temporal and dcterms:spatial can describe the temporal or spatial size (extent) of a record, for example.

DCAT only has byteSize. It was originally named size (like in this repository), but that was too confusing, and so it was renamed to byteSize. Note that DCAT was draft at that time. This repo shouldn't implement the draft; it should be updated to match the actual spec.

How can this field be reliably used by a developer? I'd be 👍 for just dropping it all together.

True - as a developer, I rarely consider file size before downloading a dataset. No issue with removing it.

Thanks for the great conversation. After careful consideration spurred in part by this issue, the decision was made to remove the 'size' field.